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Abstract 

Previous research on static analysis for program families has fo¬ 
cused on lifting analyses for single, plain programs to program fam¬ 
ilies by employing idiosyncratic representations. The lifting effort 
typically involves a significant amount of work for proving the cor¬ 
rectness of the lifted algorithm and demonstrating its scalability. In 
this paper, we propose a parameterized static analysis framework 
for program families that can automatically lift a class of type- 
based static analyses for plain programs to program families. The 
framework consists of a parametric logical specification and a para¬ 
metric variational constraint solver. We prove that a lifted algorithm 
is correct provided that the underlying analysis algorithm is correct. 
An evaluation of our framework has revealed an error in a previous 
manually lifted analysis. Moreover, performance tests indicate that 
the overhead incurred by the general framework is bounded by a 
factor of 2. 

Categories and Subject Descriptors F.3.3 [Logics and Mean¬ 
ings of Programs ]: Studies of Program Constructs-Functional 
constructs,Type structure; D.3.2 [Programming Languages ]: Lan¬ 
guage Classifications-Applicative (functional) languages 

General Terms Languages, Theory 

Keywords Variational types, constraint-based type system, static- 
analysis lifting, program families, choice calculus 

1. Introduction 

Software increasingly includes some form of variation. This can 
range from something as simple as having a few configuration op¬ 
tions represented by #ifdef annotations to fully-fledged software 
product lines (SPLs) [13], Each such variational program effec¬ 
tively encodes a (potentialy huge) number of programs and is thus 
also often called a program family [31], 

Ensuring static properties of program families is challenging be¬ 
cause the brute-force approach of generating and analyzing each in¬ 
dividual program is generally infeasible due to the sheer number of 
programs a program family may encode. 1 Thus, the design of scal¬ 
able analysis algorithms for program families has been the subject 


1 For example, MySQL contains some 900 macros. Assuming these are 
pair-wise independent binary macros, the encoded number of program 
variants is close to the number of atoms in the universe to the 4th power. 
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of much research, such as the variationalization of parsing [19, 23], 
type checking [1, 10, 17, 22, 24], dataflow analysis [5, 25], model 
checking [2, 11, 12, 14] and theorem proving [16,41]. 

Most of these approaces employ some form of “lifting” strategy 
to extend a traditional analysis algorithm to deal with variational 
code. For instance, the variability-aware module system [24] is the 
result of lifting the module system introduced by Cardelli [6], the 
variational type inference [10] is the result of lifting the algorithm 
W [15], and the variability-aware dataflow analysis [5] is a lifted 
version of the traditional intraprocedural dataflow analysis [28]. All 
these approaches follow a similar pattern that typically involves the 
following steps. 

(1) Add variability to data structures used in the traditional anal¬ 
ysis. For example, variational types are represented as sets of 
plain types [1], value sets for dataflow analysis are extended to 
functions from features to values [5], or in variational type in¬ 
ference [9, 10], types, unifiers, and typing environment are all 
made variational using an explicit choice representation [18]. 
A similar representation has been adopted in [24, 25], 

(2) Adapt analysis rules to deal with variational data structures. 
This applies in the obvious way to all data structure exten 11 
mentioned in (1). Some approaches require additional machin¬ 
ery. For example, in [10], a type equivalence relation is required 
to make comparisons with choice types less rigid, and for the 
model checking approach described in [11, 12], the nodes and 
edges of transition systems are annotated with features, leading 
to feature transition systems. 

(3) Prove that variation elimination commutes with the analysis, 
that is, a selection made from a program family and its analysis 
result should result in a plain program p and a result r such 
that running the traditional analysis on p would produce r. For 
example, the work on type checking [22] and type inference [9, 
10] presented such proof. A similar proof was absent for the 
dataflow analysis [5], but was later presented in [4], 

(4) A performance evaluation that demonstrates the efficiency gain 
of the lifted analysis over the brute-force approach. 

This commonality indicates a general mechanism to systematically 
lift traditional static analyses to make them work for program fam¬ 
ilies, avoiding the tedious steps of adding variability, performing 
proofs, and evaluating performance. So far, however, such a method 
is not available. The only attempt at something similar was recently 
made by Bodden et al. [3]. However, their approach only works for 
dataflow analyses formulated in the IFDS framework [35], 

In this paper, we propose a type-based framework for automati¬ 
cally lifting plain-program static analyses to program families. Our 
method is applicable if (a) the analysis to be lifted can be expressed 
as a type system and (b) the program family is expressed using an¬ 
notations (such as #if def CPP commands). 

We have formalized our framework based on type analysis be¬ 
cause it is both popular [30] and expressive [27]. Specifically, fol- 
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lowing the spirit of HM(X) [29], a parameterized Hindley-Milner 
type system, we design VHM(X), an extension of HM(X) with 
variational constructs and an annotation model, allowing a richer 
set of information to be tracked during type checking. The suc¬ 
cess and scope of the HM(X) has been demonstrated with a wide 
range of program analyses, such as overloading [39], conditional 
constraints [32], or flow inference [33]. It has also been extended 
by abstract polymorphic data types [37] and guarded algebraic data 
types [38]. 

1.1 A Simple Example: Control Flow Analysis 

As one example, we consider a type-based OCFA (context- 
insensitive control flow analysis), discussed by Palsberg [30], that 
answers the question “what is the potential set of functions an ex¬ 
pression may be evaluated to?” Consider, for example, the follow¬ 
ing expression introduced in [30]. 

f={(X 1 h.X 2 x.hx ) (X 3 y.y)) (A 4 z.z) 

The type-based OCFA developed in [21] computes A z.z, written as 
{4}, as the analysis result for /, meaning that / will evaluate to the 
abstraction labeled by 4. 

Now consider the following, related program family that is ob¬ 
tained by creating a choice named D between A 3 y.y and X 5 w.X 6 y.y. 

e = ({X l h.X 2 x.hx) D{{X 3 y.y), (. X 5 w.X 6 y.y ))) (A i z.z) 
Choice expressions such as D{e\ , ef) denote variation points in the 
program. They require that one of the alternatives e\ and ej be 
selected to obtain a plain program from the program family. By 
selecting the first alternative of D in e, we obtain /. If we instead 
select the second alternative, we obtain the following expression g. 

g = ((X 1 h.X 2 x.hx) {X 5 w.X 6 y.y)) (A 4 z.z) 

For g, OCFA produces the result {6}. This means that for the 
program family e we obtain the variational result D({4}, {6}), 
which reflects the fact that the result of the analysis depends on 
the selection made for D. For the first alternative, we get the result 
{4}, and for the second alternative, we get {6}. 

Since the brute-force approach of generating all variants and 
running the analysis on each variant separately doesn’t scale, a 
OCFA for program families has to work with the variation repre¬ 
sentation (choices, as shown, or other) directly. 

Now instead of having to go through the four steps sketched 
above over and over again, for each new program analysis, we 
would rather develop a method that, given a suitable representation 
of a single-program analysis, would generate a provably correct 
program-family version of that analysis automatically. 

1.2 Contributions, Perspectives, and Previous Work 

This work is related to the HM(X) system developed by Odersky 
et al. [29] and our variational type inference algorithm [10], but 
extends both significantly. 

We extend HM(X) in two ways. First, we make expressions, 
types, constraints, and also typing systems variational, which al¬ 
lows us to deal with program families. Second, types and also 
derivations are extended with annotations, which allow us to en¬ 
code more type-based analyses in the framework. 

There are also two major differences compared to our varia¬ 
tional type inference [10]. First, this paper develops an analysis 
lifting framework while the previous work was about a type in¬ 
ference algorithm for variational programs. The machinery devel¬ 
oped in this paper is more general, and the variational type infer¬ 
ence algorithm can be expressed as an instance of the lifting frame¬ 
work. Second, from a technical point of view, the need for a general 
variational constraint solving algorithm has provided a more fun¬ 
damental understanding of the problem domain. Specifically, the 


variational constraint solving algorithm developed here, while be¬ 
ing more general, is also significantly simpler than our previous 
variational unification algorithm [10] when instantiated with the 
Robinson algorithm [36], 

This paper presents a systematic approach to automatically lift 
program analyses to families of functional (and other) programs. 
Our work is based on a variation representation that we briefly re¬ 
view in Section 2. The paper then makes the following contribu- 

• We introduce the idea of an automated analysis lifting frame¬ 
work in the form of HM(X) in Section 3. 

• We present a parameterized type system that declaratively spec¬ 
ifies the computation of analyses in Section 4. We show that the 
variational analysis is sound provided the underlying analysis 

• In Section 5 we develop a constraint-based inference system for 
the type system, which is both sound and complete with respect 
to the type system. 

• In Section 6 we construct a variational constraint solver that is 
parameterized by domain-specific constraint solvers. We prove 
that the variational constraint solver is sound/most general pro¬ 
vided the underlying solver is sound/most general. 

• In Section 7 we evaluate a prototype implementation by com¬ 
paring it with manually lifted static analyses. The evaluation has 
revealed an error in one such manually lifted analysis, and has 
indicated that the runtime overhead of our approach is bounded 
by a factor of 2. 

Beyond the theoretical lifting framework, this paper has another 
important impact on programming language research. With the 
ability to lift a class of analyses, our framework makes what we 
call “property-guided product derivation” feasible. In current prac¬ 
tice, selection of programs from program families is solely based 
on features and functional properties. However, in many cases it 
would be useful to have additional selection criteria available. For 
example, selecting programs based on different side effects, differ¬ 
ent sets of exceptions, different kinds of security policies, and so 
on. Our framework enables users to express such additional non¬ 
functional requirements as part of the program selection process. 


2. Variation Representation 

In this paper, we focus on the static analyses for so-called “annota- 
tive” program families, that is, program families that are obtained 
by directly annotating program parts that vary, for example, using 
CPP directives. For concreteness, we use binary choices as pro¬ 
vided by the choice calculus [18] to represent variation. The choice 
calculus can be viewed as a restricted, yet more disciplined version 
of the C preprocessor. 

The main construct of the choice calculus is a named choice 
to represent alternatives in programs (and other artifacts). For the 
work in this paper we can assume that all choice names are glob¬ 
ally scoped and that each choice has exactly two alternatives. For 
example, the expression A(succ, odd) 1 represents the two plain ex¬ 
pressions succ 1 and odd 1. The name A is called a dimension. 

Choices can be eliminated through a selection operation, which 
applies a selector s, given by a dimension D and an index i, to 
an expression and replaces each of its choices named D by its ith 
alternative. For lambda calculus with binary choices, selection is 


40 


Term variables x, y, z 
Type variables a 
Choices A, B, D 

Constraints C 


Annotation variables j8 
Type constructors T 

Program locations l 


Expressions e 


x | X l x.e | e e | let x = e in e \ D(e, e) 

Monotypes 


W aV r >v z 

Variational types 


= T|D(0,0)|0->*0|r*0 

Constraints 

C 

O true \ <j> = tp\(p<(p \ D(C,C) \ 
CAC\3a.C 

Type schemas 

a 

= Voj3[q.0 

Annotations 

<P 

D 0 | {/} | /3 | <p U <p | D(tp, tp) 

Selectors 

s 

= D.i 

Type environments 

r 

::= 0 | r,.x >->■ a 

Substitutions 

0 

::= 0 |0,ai-»0 


Figure 1. Syntax of expressions, types, constraints, etc. 


defined as follows. 

\x%px 

\Xx.e\ s = Xx\e\ s 
lei e 2 - s - Id v kijv 

[le\\s iis = DA 

lD{ei,e 2 )\ s =\[e 2 \ s ifs = D.2 

L e 2jj) otherwise 

The selection operation essentially traverses the AST and replaces 
choices along the way; it thus extends naturally to other language 
constructs. 

For example, selecting A.l from the expression e = 
A(succ, odd) 1 results in the expression |/Ja.i = succ l- Selection 
synchronizes choices in the same dimension. For example, the ex¬ 
pression A(succ, odd) A(l, True) represents two expressions, succ 
1 and odd True, which can be obtained by one selection. In con¬ 
trast, we need two selections, one in A and one in B, to eliminate 
the choices in the expression A(succ,odd) /I(l.True). Since the di¬ 
mensions A and B are independent of one another, the choices rep¬ 
resents four plain expressions. 

Note that the choice representation is generic and can be used 
with any object language. It can thus represent variation in pro¬ 
grams, types, and other software artifacts and data structures. 

In the case of globally scoped choices, the semantics of a vari¬ 
ational expression e can be expressed as a mapping from sets of 
selectors to plain expressions. A formal definition can be found in 
[10]. For illustration, here is a simple example. 
[[A(succ,fl(odd,even)) = 

{{A.l} f-> succ 1, {A.2,5.1} i-» odd 1,{A.2,5.2} even l} 

3. VHM(X) Syntax 

We present the core syntax for VHM(X) in Section 3.1 and explain 
how to extend the syntax to encode static analyses in Section 3.2. 

3.1 Core Syntax 

We consider a parameterized type system over basic lambda calcu¬ 
lus plus let-polymorphism and choice constructs. Figure 1 presents 
the syntax of various concepts used throughout this paper. The def¬ 
inition of expressions is conventional, except for the choice con¬ 
struct (see Section 2). We also attach a label / to lambda abstrac¬ 


tions to track information about abstractions during type checking. 
In addition, we may make use of constants, such as succ and even, 
which have to appear in the initial type environment. 

Another important extension of the HM(X) framework [29] is 
the addition of annotations (<p) to types. An annotation is a set 
representing information of interest for a specific analysis. Thus, 
the definition of <p is partly unspecified, and we adopt the notation 
::D from [29] to indicate this fact. However, labels are always 
available as annotations, as is clear from the definition of <p. The 
distributive nature of choices [18] allows us to view D(q> i, tpz) U (p 
as D((pi U(p,(p 2 U<p). (The case for (p U D((p\, (pi) is symmetric.) 
This equivalence can be employed to normalize annotations such 
that choice constructs will not be nested within sets. 

The definition of monotypes is fairly simple. However, types 
can carry annotations (<p). Later we will see that monotypes are 
the only types that are allowed to appear in the type part of a type 
schema. More complicated type definitions will become part of the 
constraints that will be discussed shortly. This design decision is 
motivated by Sulzmann et al. [40], who observed that in the pres¬ 
ence of non-regular equational theories type inference may fail to 
compute principal types even with the help of a most general unifi¬ 
cation algorithm. They proposed as a solution to push complicated 
type definitions into constraints. This is what we adopt in this paper. 

The definition of variational types 0 differs from conventional 
type definitions in two aspects. First, we include choice types 
Z)(0,0) to represent variation in types. Second, since different in¬ 
stances of VHM(X) involve different type representations, we al¬ 
low each instance of VHM(X) to supply extra type definitions, 
through the use of annotated type constructors of the form TV 0. 
Type constructors can take an arbitrary number of arguments, in¬ 
cluding 0, in which case they represent primitive types, such as 
bool and int. Like monotypes, variational types are also annotated. 

The definition for constraints C is also open. However, we 
assume that the following constraints are always defined. 


(i) true denotes a constraint that is always satisfied. 

(ii) The constraint 0i = 02 represents a type equivalence require¬ 
ment between two types 01 and 0 2 . 

(iii) The constraint <Pi <(p2 imposes a partial order on annotations. 

(iv) The constraint D{Ci , C 2 ) allows a variation in constraints. 

(v) The constraints C\ A C 2 and 3a.C have the same meaning as 
in first-order logic. 


Each instance of VHM(X) may extend the definition of constraints. 

A type schema, written as Vaj3[C].T, consists of a constraint 
and a monotype. Note that it is polymorphic both over types and 
annotations. The constraint part C places a requirement on types 
and annotations that may be substituted for a and ft in t: Only 
types and annotations that satisfy C can be used. Type schemas are 
considered equivalent modulo bound variable renaming. 

We use 6 to range over substitutions. We write FV(C) for the 
set of free variables in C (where the 3 quantifier is the only binding 
symbol in constraints). We also use FV(<j) to denote the set of free 
variables in a and extend its definition to type environments T in 
the usual way. The application of substitution to constraints, type 
schemas, and type environment, written as 0(C), 0(a), and 0(F), 
respectively, is also defined in the usual way. 

Note that the definition of 0 and C allows us to shift complex 
conditions from types to constraints. For example, the expression 
A (succ, odd) has the type A(int —> int, int —> bool), which we 
can also express by saying that A(succ, odd) has the type a under 
the constraint a = A(int —> int, int —» bool). 
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3.2 Syntax Extensions 

To instantiate VHM(X) for a specific analysis, the following infor¬ 
mation must be supplied. 


C| gc 2 Cl IF C 2 C 2 IFC 3 CilhC 2 

Cl Ih C 2 Cl Ih C 3 6>(Ci) Ih Q(C 2 ) 


• A type definition to extend 0, given as a type signature -T. 

• An annotation definition .<// that extends <p. 


C4 C5 _ Cl lh Cl _ 

Clh 3a.C 3a.CjlF3a.C 2 


C Ih Ci C Ih C 2 
C6 ClhZ)(Ci,C 2 ) 


• A constraint definition to extend C. 

These components prepare the framework for the addition of the 
analysis proper, which has to be provided as an extension of the 
type system and will be discussed in Section 4.3. 

The extensibility of VHM(X) through the components 2F, , 

and offers much flexibility and allows a wide variety of analyses 
to be instantiated. In many instances, however, only a part of these 
components is needed, and VHM(X) can retain most of its default 
behavior. 

As an example, consider the OCFA. Section 1.1. The only anno¬ 
tations will be the labels for abstractions, which are already part of 
VHM(X). We thus have si = 0. Similarly, all the types and con¬ 
straints for OCFA are already present, that is, & = ^ = 0. 

For another example, consider exception analysis which tries to 
determine statically what kind of exceptions may be raised during 
the evaluation of an expression (see, for example, [28]). To instan¬ 
tiate VHM(X), we extend the type definition by a set of nullary ex¬ 
ception type constructors, that is, we define & = {EX \,... ,EX n }. 
In addition, we extend the definition of annotation with types, that 
is, ip ::=•■• | {0}, so that exception types can be type annotations. 
Finally, the constraint definition is extended by a predicate Ex <j> 
to denote that 0 is an exception type. 

4. VHM(X) Type System 

In this section we present the logical specification of the VHM(X) 
framework. We begin with the entailment relation in Section 4.1, 
which is followed by a discussion of typing rules for reasoning 
about programs in Section 4.2. We then show how to instantiate 
the logical part of VFIM(X) to encode new static analyses in Sec¬ 
tion 4.3. Finally, we investigate the property of VFIM(X) by com¬ 
paring it to HM(X) in Section 4.4. 

4.1 Constraint Entailment 

The exact interpretation of constraints depends, in general, on 
the analysis that is being implemented. However, we require con¬ 
straints to always satisfy the entailment relation defined in Figure 2. 
Intuitively, C\ IF C 2 means that the constraint Cj is more restrictive 
than C 2 . The top part of Figure 2 presents the relation with regard to 
the definition of constraints, and the bottom part defines entailment 
with regard to type equivalence constraints in particular. 

Rule Cl expresses the monotonicity of constraints, where we 
use the notation Cj I> C 2 to denote that C\ is more constrained than 
C 2 by interpreting the connective A as set union U and each primi¬ 
tive constraint C as {C}. The rule can also be understood by view¬ 
ing the constraints in a set as a conjunction, which means the set 
with more constraints is more restrictive. Rule C2 states transitivity, 
and rule C3 requires entailment to be preserved over substitution. 
Rules C4 and C5 deal with existential quantification. Since quan¬ 
tifying a constraint with 3 hides part of the constraint, it becomes 
less restrictive [29], Rules C6 to C8 handle choices between con¬ 
straints. The validity of these rules can be seen by considering the 
rules that result when making an arbitrary selection for the choice 
D. The purpose of rule C9 is to allow the decomposition of choices 
into two constraints. Again, we can verify the validity of this rule 
by eliminating the variation in this rule, which results in two rules, 
with each can be verified by the rule C1. This rule offers many op¬ 
portunities for optimization. 


Ci IF C C 2 IFC CilhC 2 C3IFC4 

D(Ci,C 2 )IFC D(Ci,C 3 )IFD(C 2 ,C 4 ) 

C9 D{C u true) /\D(true,C 2 ) IFD(Cj,C 2 ) 


El <j>i = 0 2 IF 0 2 = 0! E2 0! = (fc A 0 2 = IF 0! = (fe 
E3 IF0 = 0 E4 01 = 0 2 IF 0[0i] = 0[0^ 

E5 IF D(0,0) = 0 E6 JF.D<0i,0 2 )«M0 I Jd. 1, LfcJo.2) 

E7 CW-D^ 1 fc) = O{0|.02> 

A1 *1 ^ K 

CIF<pi <q>2 

Figure 2. Entailment relation of constraints 


For the entailment of type equivalence constraints, rules El to 
E3 express that type equivalence is reflexive, symmetric, and tran¬ 
sitive. Rule E4 states that the type equivalence relation is a congru¬ 
ence, where 0 [] denotes a type term with a hole (context) into which 
we can plug a type. Rules E5 and E6 express two fundamental in¬ 
variances of choice types. Rule E7 allows the annotations attached 
to a type constructor T that occurs in both alternatives of a choice D 
to be extracted and combined with T. This rule is valid because se¬ 
lection commutes with term construction, that is, [T 0j iS = T [0jj, 
a fact that follows immediately from the definition of selection (see 
Section 2). The importance of this rule lies in the fact that it allows 
us to represent variational types succinctly. For instance, we can 
push the choice into the term and factor 


D{(a -^—4 a) 2=4 a -^—4 a, (a ^—4 a) ^—4 a ^—4 a) 

into 

Finally, we add the rule A1 for the partial order relation < for 
annotations. Together with the rules C6 through C8, we define a 
partial ordering on variational annotations. Specific instances may 
extend the definition of ;<. 


4.2 Typing Rules 

The idea of type-based static analysis is to attach annotations to 
types and typing derivations and aggregate the information along 
the typing process [28], Different analyses introduce their own spe¬ 
cific annotations and relations between annotations that have to be 
integrated into the generic typing framework. To facilitate this flex¬ 
ibility, we parameterize the syntax-directed typing rules by a family 
of constraints, defining one particular constraint relationship R e for 
each kind of expression e. The arity of R e varies for different con¬ 
structors of e\ as a general rule of thumb, R e needs enough parame¬ 
ters to relate the annotations obtained from the premises of a typing 
rule to the annotation provided in its conclusion. The premises of 
each syntax-directed typing rule can thus be partitioned into two 
parts: (i) a specification of the relation between types and (ii) a 
specification of the relation between labels and annotations (ex- 
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VAR 

r(jc) =\mp[c].z <Pi c'ih c 

C' Ih R x (pi (pj 
C'-,T\ x: 


Abs 

C-,r,(x, t) he: t'/<Pi 
c II- Rx I <Pl 92 <P3 
C\T h X 1 x.e : T /(pi 


C;rhei :Ti/9i 
•U-*i = x 2 %x 


C\The 2 : t 2 /<P2 
C\hR App (pi <j>2 <j>3 <P4 
e 2 : T/<p 4 


Let 


C;T h e : <j/(jOi 

C;^(J^ 1 (T)l-e , : r/q>2 C Ih R Le , (pi (pi (pi 
C; r h let T = e in e 7 : x /<p 3 


Choice 

Ci;n- ei : Ti/(jOi 

C 2 ;ri-e 2 : T 2 /«j>2 P(Ci,C 2 ) \h D(x i,t 2 ) = T 

Z)(Ci,C 2 >;rhZ)( ei , e2 }: x/D^tfr) 


Sub 

C;TI- e : r/<p CIFtAt' 
C;TF e: t / /< p 

Gen 

Ci AC 2 ;T h e : x /<p 
C, A3a/3.C 2 ;r 


Weaken 

C';T h e : r/<p C\hC' 
C;T he: x /<p 

aj3#FV(Ci)UFV(r) 

e:Vaj8[C 2 ].T/(p 


that the potential exceptions that may be raised in an abstraction are 
those that may be raised by evaluating the body e. Moreover, there 
is no exception raised for defining an abstraction. 

The rule App is more subtle. For an application e\ e 2 to be 
well typed, we use a more relaxed relation than requiring the ar¬ 
gument type of e\ to match the type of e 2 . We require instead that 
the type of e\ be equivalent to a function type whose argument 
type is the type of e 2 . This relaxation effectively deals with the fact 
that choices in type expressions increase the compatibility between 
types. For example, the expression odd D( 1,2) should be consid¬ 
ered type correct even though the argument type of odd (which is 
int) is not equal to the type of D{ 1,2) (which is D(int, int)). 

The rule Let for introducing let-polymorphism simply aggre¬ 
gates the annotations obtained from the typing of the subexpres¬ 
sions [40], 

The typing for a choice expression is obtained by combining 
the result for its alternatives. Specifically, we pack corresponding 
constraints and result types into the choice that we are typing, as 
expressed by the rule Choice. 

Similar to the HM(X) framework, we use a subsumption rela¬ 
tion to allow a type to be interpreted as some other type, as cap¬ 
tured in rule Sub. The semantics of this relation is left unspecified, 
which thus allows different instances of VHM(X) to specify their 
interpretations as needed for their particular purposes. For example, 
in typing Haskell, it should be instantiated to the syntactical equal¬ 
ity relation. On the other hand, subsumption can be interpreted as 
a subtyping relation when subtyping is involved. In any case, we 
require the relation to satisfy the standard partial ordering axioms, 
the contra-variance rule for function types, plus the following rules 
for choice types. 


Simple 

C:The:c/<p aP#FV{ct)UFV{r) 
3cip.C;rhe:a/(p 

Figure 3. Typing rules for VHM(X) 


pressed by R e ). The family of constraints R e has to be instantiated 
by each specific analysis instance. Whenever the second part is not 
needed, it can be simply turned off by using the constraint true as 
instantiation. 

The typing judgment of VHM(X) has the form C;T he: cr/f, 
which computes the type schema <7 for the expression e under the 
typing assumptions in T and the constraint C that expresses the 
assumptions about free type variables in T and <7. In addition, an 
annotation (p is maintained by the typing relation. This annotation 
links the annotation constraints to the typing process and ensures 
that the information computed within the annotations is available 
as results in the type derivation. Figure 3 presents the rules for as¬ 
signing types and annotations to expressions. The syntax-directed 
rules are shown in the upper half, and the remaining rules are col¬ 
lected at the bottom. 

The rule Var allows us to instantiate a type schema VajS[C].T 
with any constraint C' as long as it entails C and the parameterized 
constraint R x (pi (p 2 is satisfied (which expresses the relationship 
between the stored and returned annotation for a variable). 

The rule Abs extends the traditional rule by a premise that de¬ 
mands the relationship Rx hold between the annotations of the ab¬ 
straction’s body (<pi), the function type ((pi), and the whole deriva¬ 
tion ((pi). Note that usually (fh collects interesting information 
about the evaluation of the abstraction while (pi collects the infor¬ 
mation about defining the abstraction [28], For example, in case 
of exception analysis (Section 4.3), the constraint is instantiated as 
% ^ <Pl <P2 03 = 01 < <P2 A< <Pi A<j(>3 < 0 A0 < 03, and denotes 


CII- 0 iX 0 CII-<fcX 0 CII- 0 A 0 ! CIF 0 A 02 

C\hD(<t> U (t> 2 )±<t> C lb £><01,02} 

C Ih 01 X 02 c IF 03 A 04 
C Ih 0(0!, 03) X 0(02,04) 

The rule Gen borrowed from [40], introduces a type schema for 
a typing judgment. The essential idea is that the constraint is split 
into two parts, one part (C 2 ) constrains the free variables in the 
result type x and the type environment T, while the other (Ci) 
doesn’t. As a result, only C 2 appears as the constraint for the result 
type schema. (We write .S) # S 2 to express that two sets Si and 
S 2 are disjoint.) Many rules exist for generalization, but this rule 
has many advantages over previous ones [29], The novel part is 
that 3a.C 2 remains in the left-hand side of the judgment, whose 
goal is to ensure that the constraint C 2 must be satisfiable. In other 
words, to generalize a type, the generalized type must at least have 
one instance. Further details motivating the use of 3a.C 2 were 
presented in [29]. 

The rule Simple allows us to hide type variables and simplifies 
the constraint part of a typing judgment. For example, in the judg¬ 
ment Eq oti; r F e : a 2 —> bool/0, the constraint is not needed, and 
we can thus transform it into Scq.Eq ai;T h e : a 2 —» bool/0. We 
don’t simply drop the constraint Eq oq, because we want to main¬ 
tain the fact that the constraint Eq oq must be satisfiable. The rule 
Weaken allows us to strengthen the constraint in a typing judgment 
while deriving the same result. 

We don’t have an instantiation rule to eliminate type schemas 
because the polymorphism is introduced through the let expres¬ 
sions and as a result, we only need to instantiate variable references, 
which is already realized in Var. 

4.2.1 Constraint Optimization 

We observe that in Gen constraints are moved from the assump¬ 
tion into type schemas whereas in Var constraints are moved in the 
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opposite order, which means that when a variable is referenced re¬ 
peatedly, the constraint from the type schema will be copied many 
times. Since it is important to keep the constraints to a manageable 
size, rules like the seemingly complicated Gen are needed to split 
constraints in premises into two parts and move as little as possi¬ 
ble to the resulting type schema. Achieving high performance is a 
main goal of the VHM(X) framework. The entailment relation de¬ 
fined in Figure 2 and the rule Weaken offer many opportunities to 
optimize the representation of constraints. As an example consider 
the following judgement. 

D(C,Eq a);r|- elem x : [a] -A bool/0 

We assume that a </ FV(C) and that C is a large, complicated con¬ 
straint. Generalizing this judgment directly with Gen will not leave 
much room for optimization since the whole constraint D(C, Eq a) 
will be copied to the result type schema. However, since C doesn’t 
constrain a, it shouldn’t be moved to the type schema. We can 
achieve a better result by first applying the Weaken rule and then 
using rule C9 from Figure 2. As a result, we first obtain the follow¬ 
ing judgment. 

D(C,true) AD(true,Eq a);F\~ elem x: [a] —bool/0 

When we now apply the rule Gen, we obtain the following judge¬ 
ment instead, which preserves the meaning: When the first alter¬ 
native of the constraint is selected, the type variable a is not con¬ 
strained and can be instantiated with any type. 

D(C,true) A3a.D(true,Eq ct);rF 

elem x:Va[D(true, Eq a)].a-lbool/0 


4.3 Typing Extensions 

To encode a specific analysis, the entailment IF relation among 
constraints may be extended, which includes an extension of = and 
< as well. Moreover, two components of the typing rules have to be 
instantiated: the subsumption relation A and the constraint relation 
S# between annotations that is used in the syntax-directed typing 
rules. £% consists of four constraint relationships R x , Rx, Rut, and 
Ra pp - Finally, types for extended expression constants have to be 
provided through the initial environment To. 

For OCFA, no extension for IF, = and < is needed. Also, the 
subsumption relation is interpreted as the type equivalence relation 
s, For.«, we get R x <p, (fr = R App Pi <P2 <P3 <P4 = Rut Pi P2 P3 = 
true, which says that for these cases the constraint always holds. 
For the Abs rule we have Rx l (p\ (fe (pi = {/} < P2, which records 
each abstraction in its resulting function type. 

As an example, consider again the expression e shown in Sec¬ 
tion 1.1. We first rewrite it as e = (e\ D(e 2,63}) 64- Based on the 
typing rules in Figure 3, we can conduct a OCFA for e. We use the 
following constraint C. 


-> cti A 04=D(a 2 ,a 3 ) 


With C the following judgments are derivable. 

„ „ s OF „ I 


C;rFD(e2,e3) : 02 - 

C;T\- e4 : 01%/0 


Now we can apply rule App twice and obtain the judgment 
C;FFe : (X4/0. Based on the annotations for 04, the result of 
OCFA for e is D({4},{6}), which is the same result we obtained 
in Section 1.1. 

As another example consider instantiating VHM(X) for type 
inference of lambda calculus with let polymorphism. There is no 
extension needed here for =, < and IF. We let A be type equality, 


which means that no extension is needed for A. Moreover, since 
type inference doesn’t involve the handling of annotations, we can 
define each constraint in to be true. 

For the exception analysis, we have to extend the type system 
as follows. First, for each exception type EX,, the relation IF Ex EXi 
is added to convey the fact that EX,- is an exception type. No 
extensions are needed for < and =. Next, each constraint that 
appears in the typing rules (Figure 3) has to be instantiated as 
follows [28] (we use (pi = (f , <px to denote (p\ < (fa A (fr < pi). 


Rx I Pi <P2 93 = 92 =<p Pi A P3 = 9 0 
RApp Pi P2 P3 P4 = 94 =<p <Pl U<?>2U<?>3 
Rut <Pl P2 93 = 93 =<p <Pl U P2 

No extension for A is required. The initial type environment should 
be as follows. 

r 0 = {(ex i ,EX i ), 

(raise, Venice [Ex a\].a\ -^—4 a 2 ), 
(handle,VaiO£2j3ij3 2 ft[Ex Cti Aj8 3 = /3 2 \{«| }]. 
cm of 1 a 2 )} 


4.4 Properties 

The most important property of VFIM(X) is its correctness, that 
is, by running a lifted analysis on a program family we obtain 
a synchronized family of analysis results such that the original 
analysis would yield for any particular program, obtained through 
a selection with a decision S, the same result that is obtained from 
the result family also by selection with S. 

The first step in establishing this result is to show that selection 
preserves the typing relation provided that the entailment relation 
is preserved over selection when the instantiated & constraints 
are involved. For example, if C IF Rx l pi (jh (fo, then |CJ S IF 
\ Rx l cpi 92 <[>3 J .v must hold. Moreover, we require that for each 
type constructor T, the relation IF \ T^ (f>\ s = rLl>J* [0]^. holds. 

Lemma 1. IfC\Y\-e : a/p, then [CJ,; |TJ S F |ej s : [aJ./LpJj. 

PROOF The proof is by an induction over the typing derivation. 
Note that for each typing rule in Figure 3, the typing relation is 
preserved over selection. 

We show one proof case for the Choice rule, which is es¬ 
tablished by induction over the structure of s. We show the case 
s = DA. (The case for .v = D. 2 is analogous, and the case when s 
is neither DA nor D. 2 follows by induction from the definition of 
selection defined in Section 2.) 

Given C|;T F e| : Ti/pi and C2;T F e2 : T2/P2. the induction 
hypotheses are that 

LCtJftl.L r Jo.i 1“ [eijo.i : iTiJo.i/hhJzu (1) 

and |C 2 Jd.i; |TJd.i F [_e 2 \ D .\ : We have to show 

[£>(Cj,e 2 )J/xi; iTJlMi F \p(ei,e 2 )\o.\ : L'Tlo.i/L^Kp i, 9>2 )Jd.i, 

which, by definition of selection, can be simplified to the following. 

lAJzu; [Tjfl.i F [eijzj.i : L T Jo.i/L < Pi_l£>.i ( 2 ) 

The additional hypothesis D(C\, C 2 ) IF D(%\ , t 2 ) = t, together with 
Lemma 2, gives us that [D(C[, C 2 )Jd.i IF LD(T|, T 2) = t:\d.I , which 
can be simplified to 

[Cijzu I ITiJd.i = LtJd.i (3) 

The result (2) we want to prove follows from (1) and (3). □ 

Lemma 2. IfC % IF C 2 , then ICjj*IF |j_C 2 J f . 
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I-Var 

T(a) = VaP [C]. T? 1 cti new /3i new 

3aft (C A ft <pi ft A «i = t (pi ); r ft * : ai /ft 


_ ftT, (A,ai) ft g ; g 2 /ft 0:3 new ft, ft new _ 

3aia 2 ft.(CAft / ft ft ft A a 3 = aj h o^rft X l x.e : a 3 /h 


Ci;rh/ei : «i/^i CftTft g 2 : g 2 /fe 
3a t 02ft ft (ft AC 2 Aft w , /3| ft ft ft A ®j A a 2 


a 3 new ft, ft new 
aj^rh/ei e 2 : a 3 /ft 


I-Let 

Ciftftgia/jS CftftftftaftCftajftg'iai/ft ft new 


(3a0 ft-(C| Aft,, p ft ft)) AC 2 ;r ft let a = « in g': a,/ft 


I-EQU 

Ci ;r I—/ g : a//3 CiJFC 2 C 2 lhCi 
C 2 ;rfte:a//3 


Ci;n-/ei :oi/ft C 2 ;T ft g 2 : a 2 /ft 0:3 new ft new 
' HC 3aia 2 ftft.(D(C l5 C 2 > AD(a 1 ,a 2 > = a 3 Aft =D(ft,ft» ; rh / D(g 1 ,g 2 > : a 3 /ft 


Figure 4. Type inference for VHM(X) 


PROOF By induction over the structure of C. □ 

Note that the reverse of Lemma 1 also holds. In expressing this 
result we use the notation ft ft} r 2 to denote an environment ft, 
for which IftMJzu =ft(x) and lftMJzj.2 = ftft) (for any 
variable x ). 

Lemma 3. If Ci;ft I- ei : Oi/tp\ and ft;ft L g 2 : C7 2 / tpi, then 
Z)(ft,ft);Fi tiJuft hZ)(gi,g 2 ) : Os/D{(p\,<pi) is derivable and 
LftJo.t = cti and Lc 3 Jz ).2 = 0 ' 2 - 

Proof Proof by contradiction with the help of Lemma 1. □ 

Based on Lemma 1, we can now state the following projection 
theorem. Any analysis for a plain program (that was selected from a 
program family) can be obtained from the corresponding family of 
results produced by the lifted analysis for the program family. We 
use 8 to range over complete decisions, which are sets of selectors 
that eliminate all the choices in C, ft a and tp. 

Theorem 1 (Projection). Given C;Tbe: a/<p, then V(ftg') e 
{C\ S \\T\ S \- e' \a'/<p', where o' = [<t']](S) and tp' = 

M («)• 

Proof The proof is based on an induction over the structures of C, 
T, <t and (p, with the help of Lemma 1. □ 

Finally, we observe that, disregarding annotations, VHM(X) 
and HM(X) compute the same result in the absence of choices. 
Using \- HM to denote the typing relation of HM(X) [40], we have 
the following result. 

Lemma 4. Given C, T and e plain, if C\T \-e \ a/tp, then 
C;T\- hm e : a', where o' can be obtained by eliminating anno¬ 
tations from o. 

Proof The proof can be established through an induction over 
the typing derivation based on the typing rules in Figure 3 and 
the rules in [40], Moreover, observe that in absence of variation 
constructs, the = relation degenerates to type equality and the 
subsumption relation A introduced in Section 4.2 degenerates to 
the same subsumption relation as in [40]. □ 

5. Parametric Type Inference 

In the specification of type-based analysis, constraints C serve as an 
input. Flowever, in implementing the analysis, we need to dynam¬ 
ically generate and solve constraints. In this section, we discuss 
constraint generation; constraint solving will follow in Section 6. 

In Figure 4 we present the inference rules for the judgment 
C;T F/ g : a/ft where T and e are the input and C, a, and J3 are 


the output. The presentation is an adaptation and extension of the 
type inference rules for HM(X) [40] to accommodate the handling 
of annotations and choices and uses the parametric constraints 
introduced in Section 4.2. 

The inference rules are derived from the corresponding typing 
rules (Figure 3) by moving the constraints in the premise to the 
left-hand side of the judgment in the conclusion. The rules gather 
constraints from subexpressions and add them to those of their 
parents to ensure correctness, that is, no conditions will be ignored. 
The minimality of constraints and thus the genrality of the inferred 
result follow from the fact that each rule only integrates constraints 
that are required for the particular construct under consideration. 

For example, in I-Var, the conclusion can be read as “when 
the constraint C is satisfied, x can have any type”. Note that T <Pl 
may contain reference to aj3, which is why the constraint a\ = T^ 1 
appears inside the quantification 3aft To consider another exam¬ 
ple, in rule I-App the constraints from subexpressions, ft and ft, 
the constraint for annotations Ra pp Pi ft ft ft, and the constraint 
between the types of gj, g 2 , and the result type of the application 
gl g 2 , are simply collected in the constraint of the conclusion. The 
rules follow a similar pattern as the typing rules in Figure 3. 

Note that there is only one non-syntax directed rule, I-Equ, 
which can be applied any time. The purpose of this rule is to keep 
the size of the constraint as small as possible by employing the 
relationships defined in Figure 2. 

Given the inference rules in Figure 4, we can generate the fol¬ 
lowing constraint ft for the expression gi = X x h.X 2 x.hx, which is 
a part of the expression g introduced in Section 1.1. The expression 
gl then has the type a 7 under the constraint ft. 

ft =3aio 2 a 3 a 4 oc5a 6 (ai = a 3 A oia = a 4 A a 3 = a 4 -^4 a 5 A 
{2} < ft A ct6 = a 2 ^ a 5 A {1} < ft A a 7 = cfc) 
The constraints for other parts of the expression g can be generated 
similarly and are omitted here. 

We now investigate the relation between type inference rules in 
Figure 4 and specification rules defined in 3. First, type inference 
is sound, as stated in the following theorem. 

Theorem 2. Z/ftTF/g : a/ft then C;Fbe : a/ft 

Proof The proof is based on an induction over the structure of the 
expression g. □ 

Also, type inference is complete and principal and least con¬ 
strained in the sense that the constraint generated by the relation h/ 
is minimal while satisfying the typing judgment discussed in Sec- 
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r-.cxo^cxe 

(a) 'r(3ap.C,0)s (C u O l \{a,p}) when {ct,j3} # vars(Q) 

where (Ci,0i) = V{C,Q) 

(b) y(D(C u C 2 ),0) = (D(C 3 ,C 4 },0 3 U D e 4 ) 

where (C 3 ,0 3 ) = r(Ci,e) 

(c 4 ,o 4 ) = y(c 2 ,e) 

( C ) y{D{c,c),e) = y{c,e) 

(d) t(C\ A C 2 ,e) = (C 3 AC 4 ,04) when Ci or C 2 not plain 

where (C 3 ,0 3 ) = r(Cj,0) 

(C 4 ,0 4 ) = r(0 3 (C 2 ),0 3 ) 

(e) r(D{<h,<h) = 0(03,04>, 0) = = fo,<h = W, 0) 

(f) r*(£»(0i,(fe) = <h,e) = nD(h =h,^2 = <h), e) 

(g) r*(a = 0,0) = (true,{(a,0)} O 0) when a £ FV(0) 

(h) = 02,0) = whenDe dims(<j>i,(lh) 

'^(£ ) (L0iJd.i = [<tejD.li L01 Jd.2 & L02Jd.2),0) 

(i) y((j> 1 = 03,0) = ^(0! = 02,0) when 0! and 0 2 plain 

(j) y(P, 0) = ^ (P, 0) when P analysis specific 

Figure 5. Variational constraint solving 


tion 4.2. We express this result in the following theorem, where we 
extend the definition of ■< to type schemas in the theorem, follow¬ 
ing a standard definition in [29]. 

Theorem 3. Given C;TF e : o/<p, thenC'\T\-j e : a/P suchthat 
C1F Bap.C', C lh Vaj3[C'].a r< <7 and C lh P < <p. 

Proof The proof is based on an induction of the derivation tree of 
C;T\-e:a/(p. □ 

6. Variational Constraint Solving 

To compute an analysis result, we need to solve the constraints 
generated in the type inference phase. Since different analyses 
will introduce quite different constraints, there will be no single 
constraint solving algorithm that solves all generated constraints. 
Therefore, our algorithm will defer to an application-specific solver 
to handle constraints that are specific to a particular analysis. 
has to be provided by the implementor of the static analysis, but 
there is potential for the reuse of one solver for different analyses. 

6.1 A Constraint Solving Algorithm 

We say a constraint is primitive if it doesn’t contain choices or 
existential quantification. In this section, we will use P to range 
over primitive constraints. 

We assume that can be applied to a given set of constraints 
Ci and a given substitution 0i and returns a residual constraint 
C 2 together with substitution 0 2 . We require that 0 2 (C 2 ) = C 2 
and C 2 lb 02(Ci). Note that constraint solving also involves the 
manipulation of mappings from p to (p. These can be treated like 
substitutions and are thus stored in 0 as well. 

Based on^,we build a variational constraint solving algorithm 
Y, shown in Figure 5, which solves the core constraints defined in 
Figure 1. The signature of y is the same as that for . In the 
following we will briefly discuss the different cases. When none 
of the cases and conditions apply, the constraint solver fails, which 
indicates that the analysis for the particular program family cannot 
produce a result. It would be nice if VHM(X) could produce partial 
results in the presence of unsolvable constraints for some program 
variants. We can envision a corresponding extension following the 
approach presented in [9]. 

Case (a) deals with existential constraints 3a/3.C, which can 
be solved by solving C and then removing the mappings for a 
and P from the result substitution (indicated in Figure 5 by using 


the notation 9\\{a,p}). The condition {a,p} # vars(Q) ensures 
that the mappings for a and p will not be removed in 0, where 
vars(6) compute the domain of 0 and all free variables in 0. Thus, 
to make this rule applicable, we may have to first rename the bound 
variables a and p. Note that when C is unsatisfiable, then so is 
BajS.C. Note also that our rule to solve existential constraints is 
simpler than the one given in [40] because our constraints are only 
based on boolean algebra and not cylindric algebra. 

Case (b) shows that solving a variational constraints D{C\,C 2 ) 
requires solving each alternative. The potentially different residual 
constraints are then combined again in a choice. The potentially 
differing substitutions are combined with the operation U, which is 
defined as follows. 


01 /)0 2 («;- 


! D(0i(a),e ,(«)) 
D(0i(a),ai) 
D(a i, 02(a)) 
a 


a G dom(9{)/\a e dom(9 2 ) 
a G dom(0\) A oqfresh 
a G dom(B 2 ) A oqfresh 
otherwise 


The reason for generating fresh type variables is to reflect the fact 
that an alternative of a choice might not have been constrained. 
For example, when a dom(0 2 ), the second alternative will be 
replaced with a fresh type variable, which allows the second alter¬ 
native to have any type. 

Case (c) allows us to save work when constraints of two alter¬ 
natives of a choice are the same, and case (d) deals with constraints 
of the form Ci AC 2 , where either C i or C 2 is not plain. (Otherwise, 
the constraints should be dealt with by W.) A conjunction is solved 
in sequence by threading updated substitutions. 

The next group of cases (e) through (i) deals with type equiv¬ 
alence constraints of the form 01 = 02. Case (e) handles choices 
in the same dimension, which reduces to solving the equivalence 
constraint between the corresponding alternatives. In case (f) one 
side is a choice while the other side is not (or a choice in a differ¬ 
ent dimension). In these cases, both alternatives of D are required 
to be equivalent with the type on the other side. The * attached 
to Y in this case (and the next) indicates that there is a dual case 
that can be handled correspondingly, where the two arguments to 
= are swapped. Rule (g) deals with the case that one side is a type 
variable a, which succeeds by extending the substitution. 

The situation becomes a little more complicated when the two 
types are of different form and contain choices, which is addressed 
by the rule (h). The general idea is to eliminate choices in the types 
so that they become simpler, which may lead to other rules being 
applicable. We achieve this by making selections into the types and 
and create a choice constraint. (The function dims determines the 
set of dimension names contained in types and expressions.) 

A potentially more efficient strategy is to inspect the structures 
of the types and take the appropriate actions. For example, if the 
constraint is of the form T 1 ? 1 0i = 02, we can instead solve 

the constraints <pi = <P2 A 01 =02- However, this works only when 
the constructor T forms a free algebra, that is, has no associated 
equational theory; it fails, for example, when T is commutative. 

For unifying two plain types, we dispatch the task to the un¬ 
derlying solver , as expressed in rule (i). Solving the constraints 
between two annotations of the form <Pi < <P2 is similar to solving 
the type equivalence constraint and will not be repeated here. 

Finally, when a constraint is domain specific, it is solved by the 
underlying solver %, as shown in case (j). 

With the constraint solving algorithm, we derive the following 
solution 0i for the constraint C\ generated in Section 5. 

0! = {« 7 i y (« 4 h 05 )^ 0 *^ {2 },ft {!}} 


Note that 0| (oq) is also the inferred type for the expression e\ 
(X 1 h.X 1 x.h x). With a little extra work, we can generate and solve 
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constraints for the other parts of the expression e (introduced in 
Section 1.1) and verify that the inference result is the same as the 
result presented in Section 4.3 for e. 

6.2 Relation to Variational Unification 

Even though the variational constraint solving algorithm presented 
in Figure 5 is more general than the variational unification algo¬ 
rithm developed in [10], it is also simpler. We will use the follow¬ 
ing example to illustrate the differences. Note that in [10] we use 
the notation = •, instead of =, to denote a unification problem. 
A(lnt,a) = A(a,Bool) 

The variational unification algorithm presented in [10] consists of 
three steps: 

(a) qualify the unification problem by attaching to each type vari¬ 
able a path of selectors for enclosing choices, 

(b) solve the qualified unification problem with a unifier for the 
qualified problem, and 

(c) complete the unifier obtained in step (b) to a unifier for the 
original unification problem. 

In the given example, we get for step (a) the following unification 
problem. 

A(lnt, 0(4.2) SA{0(4.i,Bool) 

We then obtain the following qualified unifier for step (h). 

{0(4 1 1— > Int, (X.\ 2 1—> Bool} 

Finally, step (c) yields the completed unifier [a A(lnt.Bool)}. 
The decomposition of the algorithm into three steps poses a big 
challenge to both the implementation and the correctness proof of 
the algorithm. 

Our constraint solving algorithm in Figure 5 simplifies the pre¬ 
vious algorithm through the use of context splitting (cases (e) and 
(f)) and context merging (through the operation 6\ Up do). Fol¬ 
lowing this idea, we derive for the problem Int = a the solution 
03 = (a 1—»Int} in the context of the first alternative of A and 64 = 
{an Bool} in the context of the second alternative of A. The oper¬ 
ation 6314064 produces the expected solution (a 1—> A(lnt.Bool)}. 

The constraint solving algorithm in Figure 5 has the time com¬ 
plexity 0(mn) when it is instantiated with Robinson’s unification 
algorithm, where m and n are the size of the left and right constraint, 
respectively. This is the same as the time complexity of step (b) of 
the previous variational unification algorithm. The implementation 
of the new algorithm, however, is much simpler. Moreover, proving 
the properties of the algorithm is also easier. We’ll do this next. 

6.3 Properties 

The solver 'f inherits desirable properties of '■'//. For example, 
y is sound and principal provided that is. We say (Ci, 0i) is 
principal for (C, 0) if C\ lb 0i (C) and for any other (C2,62) such 
that C2 lb 62(C) implies 0i 4 62 and C2 lb 02(Ci). Here 0i 4 02 
holds if there is some 63 such that 02 = 63 0 01 • The definition is 
similar for the case of primitive constraints. 

Theorem 4 (Soundness of V). 

If (P 1 , 0 ' p ) = <%{P, e p ) implies P' IF 0' p {P) and 0' p {P') = P', then 
(C. 0') = Y{C, 0) implies C' lh 0'(C) and 0'(C') = C'. 

Theorem 5 (Principality of f ). 

If(P', Q' p ) = <?/(?, 0 P ) implies (P'. 0') is principal for ( P ; 0 P ), then 
(■ C', O') = V (C, 0) implies {C'. O') is principal for ( C , 0). 

PROOF The proof for both theorems is based on the induction over 
the structures of constraints C. □ 


— Module FI 


C ma(C e) { 


— Module F2 

class A extends Object 



return new E() 


class C extends Object {} class E extends Object O 

class D extends C {} class F extends E {} 


— Module F3, which requires exactly either FI or F2 
Object test2 = (new A()).ma ((new A()).mc(new ObjectQ)) ; 


— Output of FFJPL 

*** Exception: Type error: Method invocation: 

new A().ma(new A().mc(new ObjectO)) is not well-formed! 


— Output of VHMX(X) 
The SPL is well typed. 


Figure 6. Discrepancy between FFJPF and VHM(X). 


Thus the solver y has the same capability as “?/. For example, 
if is the Robinson unification algorithm, then "V is a variational 
unification algorithm as developed in [10]. If ^ is the ^cfa algo¬ 
rithm [28] for OCFA analysis, then y is the solver for variational 
OCFA analysis. 

We conjecture that y and % are in the same complexity class. 
For example, when is decidable, then so is "V. Also, when '$/ is 
semi-decidable, then so is y. We leave this for future work. 

7. Evaluation 

Does our framework make true on its promise to increase the ac¬ 
curacy of analysis lifting under an acceptable amount of overhead? 
We address this question in the following two subsections. 

7.1 Reliability of Analysis Lifting 

To evaluate the accuracy of VHM(X), we could compare its output 
with our previously developed variational type inference. However, 
it might be more informative if the evaluation is conducted by com¬ 
paring VHM(X) with tools developed by other researchers. Since 
most variability-aware analyses have been done for imperative lan¬ 
guages, we have choosen the FFJPL (Feature Featherweight Java 
Product Lines) system- developed by Apel et al. [1] as our eval¬ 
uation counterpart. Another advantage of using FFJPL is that it 
demonstrates that our lifting framework is not tied to the specific 
calculus presented in this paper. Thus we have adopted our frame¬ 
work to Featherweight Java (FJ) and refer to this version as VFJ(X). 

The idea of FFJPL is to allow each module to define new 
classes, extend, or refine classes defined in another module. Each 
FFJPL program consists of a set of modules and a feature model, 
which describes how modules may be combined together. To derive 
a particular program, decisions about which modules to select have 
to be made. All selected modules constitute the product. 

For example. Figure 6 presents a small FFJPL program, which 
consists of three modules Fl, F2, and F3. The feature model (not 
shown here) requires that the presence of F3 requires exactly one 
of Fl or F2. In both modules Fl and F2, we define a class A with 
the same methods me and ma. However, note that their signatures 
are different in different modules. Module F3 contains a single 
statement for creating new objects. This product line contains 2 
valid products, one consisting of modules Fl and F3, and the other 

2 http://www.fosd.de/ffj 
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consisting of modules F2 and F3. It is easy to check that each 
product is well typed. According to the completeness theorem 
in [1], a product line is well typed if all valid products are well 
typed. Thus, the product line in Figure 6 should be well typed. 

However, while our VFJ(TC) (VFJ(X) instantiated to type 
checking) correctly reports that the product line is well typed, 
FFJPL reports, incorrectly, a type error. We have not attempted 
to debug their type system or implementation. The important les¬ 
son here is that the general lifting framework VFJ(TC) gets it right 
while the hand-crafted analysis is erroneous. 

Of course, this anecdotal piece of evidence does not prove the 
superiority of VFJ(X) or VHM(X) in general, but it is a reflection 
of the fact that the stratified approach that requires fewer definitions 
and much less implementation effort is more likely to be correct. 3 

For illustration, we present the typing rule for method invoca¬ 
tions in both systems. 

T-Invk-FFJPL _ 

r h f 0 : E H <t> V£ eE: validref(<t>.E.m) T h f: GH4> 
mtype{<t>,m,last(E)) VGeG,V7?ef: G<:H 

T-Invk-VFFJX 

C;r\-t 0 :E-\<P/<p t 

validrefc{<t>,E.m) C;Tb t: G~\ -F/tjfh 

G= G\ x ■ • ■ x G n mtypec('t>. m, lastc(E)) = H —^ F 

CIFGAH-I® c lb R Invk (pi <P2 <P3 <P4 

C ; r b f 0 .m(f): F H <J>/<p 4 

The rule T-Invk-FFJPL is a reproduction of the T-Invk m rule in [1] 
except for renaming B, C, and D to F, G, and H, respectively, to 
avoid notational conflicts. The typing relation T b t : E H <I> says 
that when feature <I> is chosen (similar to the notion about applying 
a selector to an expression), the expression t can have any potential 
mutually exclusive class type in E. An expression can have more 
than one type because the same expression can have different types 
when different modules are selected. 

We will not analyze each part of this rule. However, a notable 
difference is how types are represented. While FFJPL uses a flat list 
to represent a set of alternative types, VFJ(X) uses nested choice 
types to represent alternative types. 

The bottom line is this. An important merit of the lifting frame¬ 
work is that the correctness of a variational analysis depends only 
on the easier to establish correctness of a single analysis (and its 
correct embedding in the framework). 

7.2 Framework Runtime Overhead 

We would like to know the overhead incurred by the general ma¬ 
chineries of the lifting framework over manually lifted variational 
analysis algorithms. To this end, we have implemented VFIM(X) 
and VFJ(X) (mentioned in Section 7.1) in Haskell and compared 
three instantiations with hand-crafted analyses. 

First, we compared the FFJPL implementation with VFJ(TC) 
for 5 product lines (1 came with the FFJPL implementation and 
four others were created by us). The running time of VFJ(TC) is at 
most 32% slower than the FFJPL implementation. 

Due to the limited number of available FFJPL product fines, 
we also compared the performance of VHM(X) with our own pre¬ 
viously developed variational type inference algorithm for Varia¬ 
tional Lambda Calculus (VLC) [10] and a manually created varia¬ 
tional control-flow analysis algorithm. 


3 The definition of FFJPL is given in 26 rules, while the VFJ(X) extension 
requires only 6 mles. Moreover, the FFJPL implementation of the typing 
rules takes 250 LOC, while the VFJ(X) extension takes 30 LOC. 
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Figure 7. Efficiency comparison between VHM(X) and VLC 


For the definition of VHM(Tylnf), that is, VHM(X) instantiated 
for type inference, no extensions for ,T, ,t/, and A are needed; 
each element of is set to true , and is the Robinson unification 
algorithm [36], To instantiate VHM(X) to VHM(Tylnf), 9 LOC of 
Haskell are needed (to declare the class instance to specify ,3?). 
On the other hand, VLC has over 220 LOC of Haskell. (Here, 
we exclude the code for the Robinson unification algorithm that 
is common to both implementations.) 

We show the performance for the two analyses in Figure 7. All 
times have been measured on a laptop with a 2.8 GHz dual core 
processor and 3GB memory running GHC 7.0.2 on Windows XP. 
We reuse the test cases from [10] that represent the worst-case per¬ 
formance for VLC. The X-axis denotes the number of dimensions. 
For these cases VLC doesn’t do much better than the brute-force 
approach of generating and checking each variant individually. This 
is because there is no sharing in the expressions. For example, the 
expression with 21 dimensions essentially represents 2 21 different 
variants by using a lot of abstractions. 

The graph labeled “vhmx-naive” represents the performance of 
the most conservative strategy for solving type equivalence con¬ 
straints using rule (h) from Figure 5. When two types are non¬ 
plain and the root of the types are not choices, the constraint is 
solved by splitting it into two constraints. Although this ensures 
correctness, it misses an opportunity for sharing. For example, 
given the constraint int —»bool = int —>-D(bool, a), using (h), 
this will leads to two subproblems int —> bool = int —> bool and 
int ->■ bool = int 0£. 

An alternative, more aggressive approach exploits the fact that 
two function types are equivalent if their corresponding argu¬ 
ment and return types are equivalent. This means that we can 
decompose the above constraint into subproblems int = int and 
bool = D(bool, a), which are more efficient to solve. The graph 
labeled “vhmx” in Figure 7 shows the performance of an imple¬ 
mentation of VHM(X) that employs this strategy. 

We can observe that for the “vhmx” implementation the slow¬ 
down of VHM(X) over VLC is bounded by a factor of 2. This is 
also the case for non-worst-case expressions that offer more oppor¬ 
tunities for sharing. 

In Figure 8, we show another performance comparison between 
VHM(X), VLC, and the brute-force approach. The expressions 
used for Figure 8 are created from the expression used in Figure 7 
whose number of dimensions is 21 by expanding the expressions 
by adding choice alternatives. Note that we only show part of the 
brute-force curve because the running time of it grows exponen¬ 
tially fast in the size of expressions, and showing its whole curve 
will make the difference between “vhmx” and VLC indiscernible. 
Again we observe that the running time of “vhmx” is within a factor 
of 2 of VLC, demonstrating that the price we pay for the flexibil- 














Figure 8. Efficiency comparison between VHM(X) and VLC 
against expression sizes. 



Figure 9. Efficiency comparison between VHM(X) and manually 
created OCFA for variational programs 


ity is acceptable. An interesting phenomenon in Figure 8 is that 
there is a more conspicuous discrepancy between the performance 
of “vhmx” and “vhmx-naive” than in Figure 7. One potential reason 
for this is that there are more opportunities for sharing for the ex¬ 
pressions in Figure 8 than for those in Figure 7, and while “vhmx” 
takes the full advantage of these opportunities, “vhmx-naive” fails 
to do so. 

Finally, we have also compared the performance of 
VHM(OCFA) and a manually lifted OCFA. For this analysis 
no extension for &, srf, and < are needed. For !%, we only 
need R x l <pi <P2 (fe = {/} < <P2 as discussed in Section 4.2. For 

, we use the unification algorithm presented in [28]. Again, 
instantiating VHM(X) for VHM(OCFA) requires 9 FOC whereas 
the hand-written OCFA requires over 240 LOC in Haskell. 

Figure 9 shows the running times of the brute-force approach 
that generates each program variant and applies OCFA to each 
variant separately, VHM(OCFA) and the manually lifted OCFA. 
Note that, like in Figure 8, we can’t show the whole curve of the 
brute-force approach. To give a sense of the complexity, it takes the 
brute-force approach about 10 days to finish the case when the size 
is 18831. We observe that the slowdown of VHM(OCFA) over the 
manually created variational OCFA is bounded by 1.73. 

One possible reason for the smaller overhead for VHM(OCFA) 
compared to VHM(Tylnf) is that more of the infrastructure of 
VHM(X) is used in OCFA than in type inference. We conjecture that 
the overhead will be even lower for more complicated analyses, but 
we leave this question for future work to verify. 


8. Related Work 

The idea of this paper is inspired by the work of HM(X) [29, 40] 
and recent numerous efforts to verify properties of software product 
lines [1,2, 5,10-12,14,17,22,24, 25]. In this section, we compare 
VHM(X) with the most closely related work. 

HM(X) and extensions Odersky et al. [29] formalized an extensi¬ 
ble constraint-based type inference framework for Hindley-Milner- 
style type systems. Later, Sulzmann et al. [40] reformulated and 
improved the HM(X) framework by shifting the type descriptions 
from a type language to a constraint language. 

We have built VHM(X) on the constraint-based HM(X) frame¬ 
work [40] and have extended it by adding labels to abstractions and 
annotations to types. The computation of annotations is expressed 
through relations between annotations attached to types and typing 
derivations, which are supplied as arguments for correspondingly 
parameterized syntax-directed typing rules. As a result, VHM(X) 
can encode more static analyses than HM(X). Second, and most 
importantly, we have introduced choices to all components of static 
analyses (types, constraints, and annotations), which allows us to 
hft static analyses to variational programs. 

Type-based static analysis Type-based analysis, together with 
dataflow analysis, constraint-based analysis and abstract interpre¬ 
tation, are the main static analysis approaches [28]. 

Several type-based static analysis frameworks have been pro¬ 
posed. For example, the framework developed by Hankin and 
Metayer [20] is based on untyped lambda calculus and allows users 
to extend type as well as expression definitions. The biggest dif¬ 
ference to VHM(X) is the way in which analyses are encoded. In 
VHM(X), we use type annotations whereas in their system this is 
done by interpreting types as specific sets of values (which requires 
users to also specify mappings from types to sets of values when 
encoding a static analysis). This makes it impossible to attach in¬ 
formation to typing derivations, making the encoding of side-effect 
analysis and exception analysis close to impossible. 

Instead of building an extensible analysis framework, Prose [34] 
took another approach by formalizing static analyses in a vari¬ 
ant of System F [42]. The expressiveness of System F, together 
with the extensions, makes the proposed approach very expressive: 
some static analyses can be directly encoded without any extension 
needed from users. However, there are also some drawbacks. First, 
the problem of type checking System F is undecidable [42], which 
makes encoded static analyses undecidable as well. Second, the ex¬ 
traction of useful information is program specific and not analysis 
specific, that is, even for the same analysis different information has 
to be supplied to derive the analysis results for different programs. 
For example, to find dead expressions in a program, users first have 
to find the substitution such that the most general derivation tree for 
the program is preserved, which is not a simple task. Finally, with 
the limitation to two universes _L and T, some static analyses are 
hard to embed. For example, it is not clear how to formalize effect 
and exception analysis. 

The most important difference between VHM(X) and other 
frameworks is that instead of encoding analyses for single pro¬ 
grams, VHM(X) lifts static analyses to program families. 

Analyses for program families The software product line com¬ 
munity has developed numerous variability-aware static analysis 
approaches (see citations above). A crucial difference to VHM(X) 
is that VHM(X) is a generic framework that can be instantiated to 
different analyses. 

The main idea of variability-aware analysis is to take special ac¬ 
tions when encountering variation constructs so that a whole pro¬ 
gram family can be checked directly. Liebig et al. [25] discussed 
that the principle for variability-aware analysis is to keep variability 
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local and follow the ideas of late splitting and early joining. For ex¬ 
ample, when typing the expression id D{ succ, odd) 3, late splitting 
means we shouldn’t separate the typing before we encounter the 
choice D( succ,odd). Thus, id should only be type checked once. 
Similarly, early joining ensures 3 is also only checked once. In [10] 
we have identified that sharing and reduction are the main factors 
for improving performance in variational type inference. Sharing 
corresponds to the principle of keeping variability local. Reduction 
means to replace a choice whose alternatives have the same type 
with either alternative. In this paper, we have exploited the idea of 
sharing and reduction to make VHM(X) efficient. 

Bodden [3] has described the automatic lifting of static analyses 
to variational programs. His approach applies to dataflow analyses 
that are based on the IFDS framework [35], However, a formal 
relation between the lifted analyses and the original analyses is 
not given. In contrast, analyses that are lifted within the VHM(X) 
framework provably retain their correctness for program families. 
Choice types The concept of named choices was introduced in 
[18] as a basis for a unified and principled representation for soft¬ 
ware variations. This choice representation has facilitated a method 
for variational type inference [9, 10]. The idea of choice types was 
also adopted by Kastner et al. [24] to implement an efficient type 
checker for C programs with compilation macros and by Liebig et 
al. [25, 26] for implementing scalable type checking and dataflow 
analysis. Recently, we have successfully employed choice types for 
providing better feedback when type inference fails [7, 8], 

9. Conclusions 

Observing a growing need for static analyses for program fami¬ 
lies, we have developed the framework VHM(X) that supports the 
automatic generation of such analyses from single-program anal¬ 
yses. The two major advantages of our approach are the ability to 
reuse much of the computation infrastructure for new analyses and 
a correctness assurance (lifted analyses work correctly if the orig¬ 
inal analyses do). The presented framework helps to separate the 
concerns of static analysis and program variability, that is, any new 
program analysis can first be developed for the single-program case 
and then automatically lifted to work on program families. 
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